Code reviews are a process that software programmers use to catch bugs before the bugs become committed into a software product. Generally, the process begins with a developer being assigned a bug to fix. The developer develops a fix for the bug and codes the fix. Then one or more reviewers review the fix. The review process ensures that fixes do not produce unintended consequences and that the fix corresponds with accepted coding practices. After a fix is reviewed and approved, then it is committed to the code.
Currently two main models of doing code reviews exist. The first model is all over-the-shoulder (OTS) approach. During OTS code review, the reviewer(s) literally looks at code revisions over the shoulder of the author while the revision is being completed. A version of OTS occurs with the revisions being displayed on a large screen, in a conference room, for example. In the OTS code review model, comments and discussion between the reviewer and the author occur in real time, but typically there is no record of the conversation.
The second current model of doing code reviews occurs via email or other communication technology such as workflow tools or source code comments. In the second current model, the author packages code changes from the fix and emails those changes to the reviewer(s). Then the reviewer opens the package and a back-and-forth email discussion ensues in an attempt for the reviewer and author to come to an understanding of why certain changes were undertaken in certain ways. The emails produce a record of this conversation, but the record is of limited value due to its unwieldy nature. In each of the current models, each particular code change is either accepted, or it is rejected, or it is postponed.
Tools exist for performing the acceptance, rejection, or postponing of changes in code reviews. In such current tools, differences between the code with a bug and the code being proposed are organized by file order, and then the differences are organized by their respective positions within each file. This organization is contrary to the way that developers think about the bugs they have been assigned to fix and other tasks they are assigned to perform.